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Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


This document describes how to build PPP sessions and encapsulate PPP 
packets over Ethernet. 


Applicability 


This specification is intended to provide the facilities which are 
defined for PPP, such as the Link Control Protocol, Network-layer 
Control Protocols, authentication, and more. These capabilities 
require a point-to-point relationship between the peers, and are not 
designed for the multi-point relationships which are available in 
Ethernet and other multi-access environments. 


This specification can be used by multiple hosts on a shared, 
Ethernet to open PPP sessions to multiple destinations via one or 
more bridging modems. It is intended to be used with broadband 
remote access technologies that provide a bridged Ethernet topology, 
when access providers wish to maintain the session abstraction 
associated with PPP. 
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This document describes the PPP Over Ethernet encapsulation that is 
being deployed by RedBack Networks, RouterWare, UUNET and others. 


1. Introduction 


Modern access technologies are faced with several conflicting goals. 
It is desirable to connect multiple hosts at a remote site through 
the same customer premise access device. It is also a goal to 
provide access control and billing functionality in a manner similar 
to dial-up services using PPP. In many access technologies, the most 
cost effective method to attach multiple hosts to the customer 
premise access device, is via Ethernet. In addition, it is desirable 
to keep the cost of this device as low as possible while requiring 
little or no configuration. 


PPP over Ethernet (PPPoE) provides the ability to connect a network 
of hosts over a simple bridging access device to a remote Access 
Concentrator. With this model, each host utilizes it's own PPP stack 
and the user is presented with a familiar user interface. Access 
control, billing and type of service can be done on a per-user, 
rather than a per-site, basis. 


To provide a point-to-point connection over Ethernet, each PPP 
session must learn the Ethernet address of the remote peer, as well 
as establish a unique session identifier. PPPoE includes a discovery 
protocol that provides this. 


2. Conventions 


The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
document, are to be interpreted as described in [2]. 


3. Protocol Overview 


PPPoE has two distinct stages. There is a Discovery stage and a PPP 
Session stage. When a Host wishes to initiate a PPPoE session, it 
must first perform Discovery to identify the Ethernet MAC address of 
the peer and establish a PPPoE SESSION ID. While PPP defines a 
peer-to-peer relationship, Discovery is inherently a client-server 
relationship. In the Discovery process, a Host (the client) 
discovers an Access Concentrator (the server). Based on the network 
topology, there may be more than one Access Concentrator that the 
Host can communicate with. The Discovery stage allows the Host to 
discover all Access Concentrators and then select one. When 
Discovery completes successfully, both the Host and the selected 
Access Concentrator have the information they will use to build their 
point-to-point connection over Ethernet. 
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The Discovery stage remains stateless until a PPP session is 
established. Once a PPP session is established, both the Host and 
the Access Concentrator MUST allocate the resources for a PPP virtual 
interface. 


4. Payloads 


The following packet formats are defined here. The payload contents 
will be defined in the Discovery and PPP sections. 


An Ethernet frame is as follows: 


1 
0-12 23:45 6 7 89.0.1 2:3-4.5 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
DESTINATION ADDR 
(6 octets) 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
SOURCE_ADDR 
(6 octets) 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
ETHER TYPE (2 octets) 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


:+ 一 + 一 一 一 + 一 
+ 一 + 一 一 一 + 一 


a 


payload 


1 
a 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
CHECKSUM 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


+ 


The DESTINATION_ADDR field contains either a unicast Ethernet 
destination address, or the Ethernet broadcast address (Oxffffffff). 
For Discovery packets, the value is either a unicast or broadcast 
address as defined in the Discovery section. For PPP session 
traffic, this field MUST contain the peer’s unicast address as 
determined from the Discovery stage. 


The SOURCE_ADDR field MUST contains the Ethernet MAC address of the 
source device. 


The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864 
(PPP Session Stage). 
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The Ethernet payload for PPPoE is as follows: 


1 2 3 
Oo 25 23. Br: 78D Oo 273-4. 5/06 77-8. 9-01. 2: 3-4» 6 7-89. 0-1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| vER | TYPE | CODE | SESSION ID 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LENGTH | payload Š 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The VER field is four bits and MUST be set to 0x1 for this version of 
the PPPOE specification. 


The TYPE field is four bits and MUST be set to 0x1 for this version 
of the PPPoE specification. 


The CODE field is eight bits and is defined below for the Discovery 
and PPP Session stages. 


The SESSION ID field is sixteen bits. It is an unsigned value in 
network byte order. It’s value is defined below for Discovery 
packets. The value is fixed for a given PPP session and, in fact, 
defines a PPP session along with the Ethernet SOURCE ADDR and 
DESTINATION ADDR. A value of Oxffff is reserved for future use and 
MUST NOT be used 


The LENGTH field is sixteen bits. The value, in network byte order, 
indicates the length of the PPPoE payload. It does not include the 
length of the Ethernet or PPPoE headers. 


5. Discovery Stage 


There are four steps to the Discovery stage. When it completes, both 
peers know the PPPoE SESSION ID and the peer's Ethernet address, 
which together define the PPPoE session uniquely. The steps consist 
of the Host broadcasting an Initiation packet, one or more Access 
Concentrators sending Offer packets, the Host sending a unicast 
Session Request packet and the selected Access Concentrator sending a 
Confirmation packet. When the Host receives the Confirmation packet, 
it may proceed to the PPP Session Stage. When the Access 
Concentrator sends the Confirmation packet, it may proceed to the PPP 
Session Stage. 


All Discovery Ethernet frames have the ETHER TYPE field set to the 
value 0x8863. 
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The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type- 
length-value) construct and is defined as follows: 


I 2 3 
Oy 2) 3 4 D0" PBS 9S OAs 23) 4 5. 67 O De 2 .34 :90 eB 9.0. (4 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| TAG_TYPE | TAG_LENGTH | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| TAG VALUE ... i 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


TAG TYPE is a sixteen bit field in network byte order. Appendix A 
contains a list of all TAG TYPEs and their TAG VALUEs. 


TAG LENGTH is a sixteen bit field. It is an unsigned number in 
network byte order, indicating the length in octets of the TAG VALUE. 


If a discovery packet is received with a TAG of unknown TAG TYPE, the 
TAG MUST be ignored unless otherwise specified in this document. 

This provides for backwards compatibility if/when new TAGs are added. 
If new mandatory TAGs are added, the version number will be 
incremented. 


Some example Discovery packets are shown in Appendix B. 
5.1 The PPPoE Active Discovery Initiation (PADI) packet 


The Host sends the PADI packet with the DESTINATION ADDR set to the 
broadcast address. The CODE field is set to 0x09 and the SESSION ID 
MUST be set to 0x0000. 


The PADI packet MUST contain exactly one TAG of TAG TYPE Service- 
Name, indicating the service the Host is requesting, and any number 
of other TAG types. An entire PADI packet (including the PPPoE 
header) MUST NOT exceed 1484 octets so as to leave sufficient room 
for a relay agent to add a Relay-Session-Id TAG. 


5.2 The PPPoE Active Discovery Offer (PADO) packet 
When the Access Concentrator receives a PADI that it can serve, it 
replies by sending a PADO packet. The DESTINATION ADDR is the 


unicast address of the Host that sent the PADI. The CODE field is 
set to 0x07 and the SESSION ID MUST be set to 0x0000. 
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The PADO packet MUST contain one AC-Name TAG containing the Access 
Concentrator's name, a Service-Name TAG identical to the one in the 
PADI, and any number of other Service-Name TAGs indicating other 
Services that the Access Concentrator offers. If the Access 
Concentrator can not serve the PADI it MUST NOT respond with a PADO. 


5.3 The PPPoE Active Discovery Request (PADR) packet 


Since the PADI was broadcast, the Host may receive more than one 
PADO. The Host looks through the PADO packets it receives and 
chooses one. The choice can be based on the AC-Name or the Services 
offered. The Host then sends one PADR packet to the Access 
Concentrator that it has chosen. The DESTINATION ADDR field is set 
to the unicast Ethernet address of the Access Concentrator that sent 
the PADO. The CODE field is set to 0x19 and the SESSION ID MUST be 
set to 0x0000. 


The PADR packet MUST contain exactly one TAG of TAG TYPE Service- 
Name, indicating the service the Host is requesting, and any number 
of other TAG types. 


5.4 The PPPoE Active Discovery Session-confirmation (PADS) packet 


When the Access Concentrator receives a PADR packet, it prepares to 
begin a PPP session. It generates a unique SESSION ID for the PPPoE 
Session and replies to the Host with a PADS packet. The 
DESTINATION ADDR field is the unicast Ethernet address of the Host 
that sent the PADR. The CODE field is set to 0x65 and the SESSION ID 
MUST be set to the unique value generated for this PPPoE session. 


The PADS packet contains exactly one TAG of TAG TYPE Service-Name, 
indicating the service under which Access Concentrator has accepted 
the PPPoE session, and any number of other TAG types. 


If the Access Concentrator does not like the Service-Name in the 
PADR, then it MUST reply with a PADS containing a TAG of TAG TYPE 
Service-Name-Error (and any number of other TAG types). In this case 
the SESSION ID MUST be set to 0x0000. 


5.5 The PPPoE Active Discovery Terminate (PADT) packet 


This packet may be sent anytime after a session is established to 
indicate that a PPPoE session has been terminated. It may be sent by 
either the Host or the Access Concentrator. The DESTINATION ADDR 
field is a unicast Ethernet address, the CODE field is set to Oxa7 
and the SESSION ID MUST be set to indicate which session is to be 
terminated. No TAGs are required. 
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When a PADT is received, no further PPP traffic is allowed to be sent 
using that session. Even normal PPP termination packets MUST NOT be 
sent after sending or receiving a PADT. A PPP peer SHOULD use the 
PPP protocol itself to bring down a PPPoE session, but the PADT MAY 
be used when PPP can not be used. 


6. PPP Session Stage 


Once the PPPoE session begins, PPP data is sent as in any other PPP 
encapsulation. All Ethernet packets are unicast. The ETHER TYPE 
field is set to 0x8864. The PPPoE CODE MUST be set to 0x00. The 
SESSION ID MUST NOT change for that PPPoE session and MUST be the 
value assigned in the Discovery stage. The PPPoE payload contains a 
PPP frame. The frame begins with the PPP Protocol-ID. 


An example packet is shown in Appendix B. 
7. LCP Considerations 


The Magic Number LCP configuration option is RECOMMENDED, and the 
Protocol Field Compression (PFC) option is NOT RECOMMENDED. An 
implementation MUST NOT request any of the following options, and 
MUST reject a request for such an option: 


Field Check Sequence (FCS) Alternatives, 
Address-and-Control-Field-Compression (ACFC), 
Asynchronous-Control-Character-Map (ACCM) 


The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a 
larger size than 1492. Since Ethernet has a maximum payload size of 
1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 
2 octets, the PPP MTU MUST NOT be greater than 1492. 


It is RECOMMENDED that the Access Concentrator ocassionally send 
Echo-Request packets to the Host to determine the state of the 
session. Otherwise, if the Host terminates a session without sending 
a Terminate-Request packet, the Access Concentrator will not be able 
to determine that the session has gone away. 


When LCP terminates, the Host and Access concentrator MUST stop using 
that PPPoE session. If the Host wishes to start another PPP session, 
it MUST return to the PPPoE Discovery stage. 
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8. Other Considerations 


When a host does not receive a PADO packet within a specified amount 
of time, it SHOULD resend it's PADI packet and double the waiting 
period. This is repeated as many times as desired. If the Host is 
waiting to receive a PADS packet, a similar timeout mechanism SHOULD 
be used, with the Host re-sending the PADR. After a specified number 
of retries, the Host SHOULD then resend a PADI packet. 


The ETHER TYPEs used in this document (0x8863 and 0x8864) have been 


assigned by the IEEE for use by PPP Over Ethernet (PPPoE). Use of 
these values and the PPPoE VER (version) field uniquely identify this 
protocol. 


UTF-8 [5] is used throughout this document instead of ASCII.  UTF-8 
supports the entire ASCII character set while allowing for 
international character sets as well. See [5] for more details. 


9. Security Considerations 


To help protect against Denial of Service (DOS) attacks, the Access 
Concentrator can employ the AC-Cookie TAG. The Access Concentrator 
SHOULD be able to uniquely regenerate the TAG VALUE based on the PADR 
SOURCE ADDR. Using this, the Access Concentrator can ensure that the 
PADI SOURCE ADDR is indeed reachable and can then limit concurrent 
sessions for that address. What algorithm to use is not defined and 
left as an implementation detail. An example is HMAC [3] over the 
Host MAC address using a key known only to the Access » Concentrator. 
While the AC-Cookie is useful against some DOS attacks, it can not 
protect against all DOS attacks and an Access Concentrator MAY employ 
other means to protect resources. 


While the AC-Cookie is useful against some DOS attacks, it can not 
protect against all DOS attacks and an Access Concentrator MAY employ 
other means to protect resources. 


Many Access Concentrators will not wish to offer information 
regarding what services they offer to an unauthenticated entity. In 
that case the Access Concentrator should employ one of two policies. 
It SHOULD never refuse a request based on the Service-Name TAG, and 
always return the TAG VALUE that was sent to it. Or it SHOULD only 
accept requests with a Service-Name TAG with a zero TAG LENGTH 
(indicating any service). The former solution is RECOMMENDED. 
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Appendix A 
TAG TYPES and TAG VALUES 
0x0000 End-Of-List 


This TAG indicates that there are no further TAGs in the list. The 
TAG LENGTH of this TAG MUST always be zero. Use of this TAG is 
not required, but remains for backwards compatibility. 


0x0101 Service-Name 


This TAG indicates that a service name follows. The TAG VALUE is 
an UTF-8 string that is NOT NULL terminated. When the TAG LENGTH 
is zero this TAG is used to indicate that any service is 
acceptable. Examples of the use of the Service-Name TAG are to 
indicate an ISP name or a class or quality of service. 


0x0102 AC-Name 


This TAG indicates that a string follows which uniquely identifies 
this particular Access Concentrator unit from all others. It may 
be a combination of trademark, model, and serial id information, 
or simply an UTF-8 rendition of the MAC address of the box. It is 
not NULL terminated. 


0x0103 Host-Uniq 


This TAG is used by a Host to uniquely associate an Access 
Concentrator response (PADO or PADS) to a particular Host request 
(PADI or PADR). The TAG VALUE is binary data of any value and 
length that the Host chooses. It is not interpreted by the Access 
Concentrator. The Host MAY include a Host-Uniq TAG in a PADI or 
PADR. If the Access Concentrator receives this TAG, it MUST 
include the TAG unmodified in the associated PADO or PADS 
response. 


0x0104 AC-Cookie 


This TAG is used by the Access Concentrator to aid in protecting 
against denial of service attacks (see the Security Considerations 
section for an explanation of how this works). The Access 
Concentrator MAY include this TAG in a PADO packet. If a Host 
receives this TAG, it MUST return the TAG unmodified in the 
following PADR. The TAG VALUE is binary data of any value and 
length and is not interpreted by the Host. 
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0x0105 Vendor-Specific 


This TAG is used to pass vendor proprietary information. The 
first four octets of the TAG VALUE contain the vendor id and the 
remainder is unspecified. The high-order octet of the vendor id 
is 0 and the low-order 3 octets are the SMI Network Management 
Private Enterprise Code of the Vendor in network byte order, as 
defined in the Assigned Numbers RFC [4]. 


Use of this TAG is NOT RECOMMENDED. To ensure inter-operability, 
an implementation MAY silently ignore a Vendor-Specific TAG. 


0x0110 Relay-Session-Id 


This TAG MAY be added to any discovery packet by an intermediate 
agent that is relaying traffic. The TAG VALUE is opaque to both 
the Host and the Access Concentrator. If either the Host or 
Access Concentrator receives this TAG they MUST include it 
unmodified in any discovery packet they send as a response. All 
PADI packets MUST guarantee sufficient room for the addition of a 
Relay-Session-Id TAG with a TAG VALUE length of 12 octets. 


A Relay-Session-Id TAG MUST NOT be added if the discovery packet 
already contains one. In that case the intermediate agent SHOULD 
use the existing Relay-Session-Id TAG. If it can not use the 
existing TAG or there is insufficient room to add a Relay- 
Session-Id TAG, then it SHOULD return a Generic-Error TAG to the 
sender. 


0x0201 Service-Name-Error 


This TAG (typically with a zero-length data section) indicates 
that for one reason or another, the requested Service-Name request 
could not be honored. 


If there is data, and the first octet of the data is nonzero, then 
it MUST be a printable UTF-8 string which explains why the request 
was denied. This string MAY NOT be NULL terminated. 


0x0202 AC-System-Error 
This TAG indicates that the Access Concentrator experienced some 
error in performing the Host request. (For example insufficient 


resources to create a virtual circuit.) It MAY be included in 
PADS packets. 
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If there is data, and the first octet of the data is nonzero, then 
it MUST be a printable UTF-8 string which explains the nature of 
the error. This string MAY NOT be NULL terminated. 


0x0203 Generic-Error 


This TAG indicates an error. It can be added to PADO, PADR or 
PADS packets when an unrecoverable error occurs and no other error 
TAG is appropriate. If there is data then it MUST be an UTF-8 
string which explains the nature of the error. This string MUST 
NOT be NULL terminated. 
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Appendix B 
The following are some example packets: 
A PADI packet: 


1 2 3 
Q0 1-2 3.4.5 6 7 8 9-0.1 2 3 4.5.6.7 8.9 0 L1:2- 3 4:5 6 7-8 9.0.1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Oxffffffff | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Oxffff | Host_mac_addr | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Host mac addr (cont) | 


| TAG_TYPE = 0x0101 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


TAG LENGTH = 0x0000 | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| ETHER TYPE = 0x8863 | v=1 |t=1 | CODE = 0x09 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| SESSION_ID = 0x0000 | LENGTH = 0x0004 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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A PADO packet: 


1 2 3 

9 :2.9 4,5 6 4.8.9 0 1.23.4 5-6 7.8.9 0 L2 34 56 7.8 9 5 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Host_mac_addr | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Host_mac_addr (cont) | Access_Concentrator_mac_addr | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Access_Concentrator_mac_addr (cont) 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| ETHER_TYPE = 0x8863 |v=1|t=1 | CODE = 0x07 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| SESSION_ID = 0x0000 | LENGTH = 0x0020 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0x47 | Ox6f | 0x20 | 0x52 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0x65 | 0x64 | 0x42 | 0x61 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0x63 | 0x6b | 0x20 | 0x2d | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0x20 | 0x65 | 0x73 | 0x68 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0x73 | 0x68 | 0x65 | 0x73 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0x68 | Ox6f | Ox6f | 0x74 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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A PPP LCP packet: 
PPP payload is left to the reader. 
the Access Concentrator. 


1 
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The PPP protocol value is shown 


February 1999 


(0xc021) but the 
This is a packet from the Host to 


2 3 


OE 2 3 407590109 77.:8::9.0 5.2.4 4 $0677 B09 0 L 2-3 4 $ € y:8.9- 01 
*—R—-R——4-x-.-4—4-— -.-4-—L—.- ta L4 —.-x4-4BM 4-444 Y 
| Access_Concentrator_mac_addr 
Pot e a e a A A a E BM E E a a a a a a BY 


|Access_Concentrator_mac_addr (c) 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
| Host_mac_addr 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
| ETHER_TYPE 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
| SESSION_ID = 0x1234 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
| PPP PROTOCOL = 0xc021 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
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